Add NUOPC cap and rearrange driver directory#376
Conversation
|
I ran full test suite on gordon and izumi. Results are here, #7358329830af, https://github.com/CICE-Consortium/Test-Results/wiki/cice_by_hash_forks |
phil-blain
left a comment
There was a problem hiding this comment.
I don't have experience with pio or cesm coupling, so I won't comment on theses changes or the nu_diag stuff.
I read the updates to the documentation and I think it's good to go.
|
|
||
| - setup of the batch scripts (in **cice.batch.csh**) | ||
|
|
||
| - setup of the model launch (in **cice.launch.csh**) |
There was a problem hiding this comment.
Thanks for that! I had noticed a few months ago that we did not mention cice.launch.csh and it was on my backlog to do a PR for that before the tutorial!
| Adding a New Driver | ||
| ------------------------ | ||
|
|
||
| The drivers directory contains two-levels of subdirectories. The first layer indicates the coupling infrastructure or strategy and the second later indicates the application or coupler the driver is written for. At the present time, the directory structures looks like:: |
There was a problem hiding this comment.
"two-levels" -> "two levels"
There was a problem hiding this comment.
Good catch, this is clearly incorrect. I have just pushed a fix.
|
side note: the Travis CI build succeeded but its status is not updated in the PR page, I wonder why... |
eclare108213
left a comment
There was a problem hiding this comment.
Looks good, just a couple of very minor editorial changes:
In dg_driver.rst, change
At the present time, the directory structures looks like::
to
At the present time, the directory structure is
In ug_running.rst, change "four basis issues" to "four basic issues"
|
Thanks @eclare108213, I have updated the documentation again. Will wait for checks to complete then will probably merge. |
|
Aren't all of the driver interfaces essentially calling subroutines? |
|
@eclare108213, that's largely true unless you are running multiple executable and coupling thru a low level interface. The difference between subroutine and mct/nuopc/esmf/oasis is the subroutine interfaces are relatively arbitrary and defined by the application, not by a formal coupling interface. Think of an ocean model calling cice from the middle of it's subroutines with some arbitrary calls, maybe directly into cice or maybe into some layer on cice. It's not really a formal layer of infrastructure. I thought about whether subroutine was a good directory name and decided it was ok. In hindsight, maybe it isn't. We can rename the "subroutine" driver directory if you'd like. How about "subprogram" or "other" or something else? Anyone have any other ideas? |
|
I was thinking the same thing. The main idea is that this form of coupling treats the ice model much less independently, more integrated. What about something like 'subsidiary' or 'direct' or something like that? |
|
I like direct over subroutines and have just changed that. Good idea. |
|
Just FYI that I am going to merge this today unless there are any other comments. I'd like to get it in before the automated testing for the weekend if it's ready. |
| setenv ICE_HSTDIR ${ICE_RUNDIR}/history | ||
| setenv ICE_LOGDIR ${ICE_CASEDIR}/logs | ||
| setenv ICE_DRVOPT cice | ||
| setenv ICE_DRVOPT standalone/cice |
There was a problem hiding this comment.
@apcraig I noticed that this change from drivers/cice to drivers/standalone/cice was not reflected in the cice.settings documentation, that still references cice. Minor, but still thought I'd mention it.
There was a problem hiding this comment.
Good catch, I'll update it in a sandbox that I plan to PR soon. Thanks!
PR checklist
Add NUOPC cap and rearrange the driver directory
apcraig
Tested on cheyenne, full test suite, bit-for-bit
Also tested on a CESM2 T62_g37 DTEST compset, successfully ran 5 days with CMEPS
Adds driver/nuopc/cmeps which was successfully tested with CESM2 at T62_g37 with DTEST.
Renames driver/cesm to driver/mct/cesm1
Renames driver/cice to driver/standalone/cice
Renames driver/hadgem3 to driver/subroutine/hadgem3
Refactored some aspects of the nu_diag initialization because CMEPS + NUOPC introduces the requirement that the coupling cap initializes the CICE log file. I have provided feedback that this is not an ideal approach because it will create differences with other caps and other applications, but that largely went in one ear and out the other. There are other ways this could be handled in CICE6, but in the end, we want to keep the initialization in the cice_init routine, so we have to be able to "detect" when nu_diag has been set earlier in those cases.
Documentation was added to provide some information about the drivers directory.